ECS Auto Scalingのヘルスチェックが通らず、起動⇄削除の無限ループになってしまう際の挙動について調査してみた

今回の調査テーマ

こんにちはAWS事業本部コンサルティング部のこーへいです。

今回の調査テーマは「ECS Auto Scalingのヘルスチェックが通らず、起動⇄削除の無限ループになってしまう際の挙動について」です。

調査を行う背景

今回は上記構成図のようにECS Auto Scalingを使用しているケースにて、AZ障害ではないものの片方のAZにてヘルスチェックが失敗してタスクが落ちてしまう場合に、再起動するタスクのAZがどのように選択されるかが気になりました。

Amazon EC2 Auto Scalingのメリットでは、以下のような記述があるもののECSでも同様の挙動を行うのか検証します。

Amazon EC2 Auto Scaling は自動的に、有効化された各アベイラビリティーゾーン内で等しい数のインスタンスを維持しようと試みます。Amazon EC2 Auto Scaling は、インスタンス数が最も少ないアベイラビリティーゾーンで新しいインスタンスの起動を試みることによって、これを実行します。アベイラビリティーゾーンに対して複数のサブネットが選択されている場合、Amazon EC2 Auto Scaling はアベイラビリティーゾーンからサブネットをランダムに選択します。この試みが失敗した場合、Amazon EC2 Auto Scaling は成功するまで別のアベイラビリティーゾーンでのインスタンスの起動を試みます。

調査してみる

今回はAZ障害が発生している状況ではなく、片方のAZにてヘルスチェックが失敗する状況を想定しています。

つまりタスクの起動自体は成功するものの、ヘルスチェックが失敗しオートスケーリング機能によってタスクが終了してしまう状況です。

なので片方のAZへの通信をSGのルールを変更することで遮断し、上記のような状況を再現してみます。

2AZ体制かつタスク数が2つの場合

まずは2AZ体制かつ、オートスケーリングのタスク数が2つの場合で検証してみます。

また片方のAZのヘルスチェックは成功し、もう片方のAZのヘルスチェックは失敗するようになっています。

結論としてヘルスチェックが失敗するAZの方で、タスクの起動⇄削除の無限ループの現象が観測されました。

最終的にはヘルスチェックが成功するAZ側で2台ともタスクが起動することを期待したのですが、AZ自体は障害ではない=タスク起動自体は成功するので、タスク数がAZ間で均等になるようにヘルスチェックが失敗するAZで起動し続けてしまうようです。

3AZ体制かつタスク数が2つの場合

今度は3AZ体制かつ、オートスケーリングのタスク数が2つの場合で検証してみます。

また3つのAZの内、2つはヘルスチェックは成功し、残り1つはヘルスチェックが失敗するようになっています。

結論としては、最終的にヘルスチェックが成功する2つのAZで2台のタスクが起動する形となりました。

具体的な流れを説明すると、AZ-A,C,DがあってAZ-Dのみヘルスチェックが失敗する場合に、最初に起動する2台のタスクがAZ-CとAZ-Dに配置されたとします。

その場合に、ヘルスチェックの失敗するAZ-Dに配置されたタスクが終了し、「タスクが配置されていない方の、ヘルスチェックが成功するAZ-A」と「ヘルスチェックが失敗するAZ-D」からランダムに、再度タスクが起動するAZが選択されます。

最終的にヘルスチェックが成功するAZ-Aが選択された時点で2台のタスクが正常稼働し続けるという流れです。

#	選択されたAZ
1回目	ヘルスチェックが失敗するAZ
2回目	ヘルスチェックが失敗するAZ
3回目	ヘルスチェックが成功するAZ
4回目	ヘルスチェックが成功するAZ
5回目	ヘルスチェックが失敗するAZ
6回目	ヘルスチェックが失敗するAZ
7回目	ヘルスチェックが失敗するAZ
8回目	ヘルスチェックが成功するAZ
9回目	ヘルスチェックが失敗するAZ
10回目	ヘルスチェックが失敗するAZ
11回目	ヘルスチェックが失敗するAZ
12回目	ヘルスチェックが成功するAZ
13回目	ヘルスチェックが失敗するAZ
14回目	ヘルスチェックが成功するAZ

14回検証したところ、選択されるAZはランダムなことが分かりました(どちらのAZが選ばれてもタスク数が均等に分散されている状況の場合)。
※ヘルスチェックが成功するAZにて起動した場合は、手動でタスクを終了させて検証を続行しています。

3AZ体制かつタスク数が3つの場合

最後は3AZ体制かつ、オートスケーリングのタスク数が3つの場合で検証してみます。

また3つのAZの内、2つはヘルスチェックは成功し、残り1つはヘルスチェックが失敗するようになっています。

結論としては「2AZ体制かつタスク数が2つの場合」と同様の理由にて、3台目のタスクがヘルスチェックが失敗するAZでの起動⇄削除の無限ループ現象が観測されました。

リソースが足りない場合の対処法

上記の検証からヘルスチェックが成功するAZの数までは、オートスケーリングするタスク数は正常稼働できることがわかりました。

しかしその数以上のタスクを増やさないと、リソースが足りない場合にどうしたらいいのでしょうか？

対策案の1つとして、タスクをサービスからではなく単体で起動して手動でターゲットグループに一時的に追加する方法が検討できるかと思います。

上記にてタスクを単体起動を行います。

タスクが起動したら、手動でターゲットグループに登録します。

とはいえ手作業が入ってしまうのはヒューマンエラーを含めてあまり賢そうなやり方とはいえないですね。 自動的に解決できる仕組みがあればいいのですが、思いつきませんでした、、、

まとめ

今回はECS Auto Scalingの挙動について調査してみました。 概ね予想通りとはいえ無限ループに対する対処についてはしっかりと考える必要がありますね。

今回の調査がどなたかの役に立てば幸いです。